Agent는 아이디어가 아니라 시스템이다

AI Agent 이야기를 하면 대부분 이런 구조를 이야기합니다.

User
 ↓
Agent
 ↓
LLM
 ↓
Tools

이 구조는 개념적으로는 맞습니다.

하지만 실제 서비스를 만들기 시작하면 곧 이런 질문이 등장합니다.

“그래서 실제로 어떤 기술로 구현하는데?”

이

질문이 중요한 이유가 있습니다.

AI Agent는 단순한 AI 모델이 아니라 여러 시스템이 결합된 플랫폼이기 때문입니다.

• - LLM
  - 백엔드 서버
  - 큐 시스템
  - 상태 저장
  - 이벤트 스트림
  - 툴 실행 환경

이 모든 것이 함께 동작해야 하나의 Agent 서비스가 만들어집니다.

그래서 실제 AI Agent 서비스는 보통 이런 기술 스택 조합으로 만들어집니다.

API Layer : FastAPI / Node
Agent Runtime : LangGraph / Custom Orchestrator
LLM Layer : OpenAI / Claude / Local Llama
Task Queue : Redis / Celery / RabbitMQ
State Store : PostgreSQL / Redis / Vector DB
Tool Execution : Python Sandbox / Docker / VM
Event Streaming : WebSocket / Kafka

이제 각각을 조금 더 현실적인 관점에서 살펴보겠습니다.

1. API Layer : Agent의 입구

모든 서비스에는 입구가 있습니다.

AI Agent도 마찬가지입니다. 사용자의 요청은 보통 이렇게 들어옵니다.

Frontend
 ↓
API
 ↓
Agent Orchestrator

그래서 대부분의 Agent 시스템은 먼저 API 서버부터 시작합니다.

개발자들이 많이 사용하는 스택은 다음과 같습니다.

• - Python 기반

• - FastAPI

• - Flask

• - Node 기반

• - Express

• - NestJS

특히 FastAPI는 Agent 프로젝트에서 매우 많이 사용됩니다.

이유는 간단합니다.

• - Python 생태계

• - AI 라이브러리 호환성 및 async 지원

즉 대부분의 Agent 시스템은

FastAPI
+
Python

조합에서 시작합니다.

2. Agent Runtime : Orchestrator

Agent 시스템의 핵심은 Orchestrator입니다.

이 Orchestrator가 하는 일은 간단합니다.

LLM 호출
 ↓
Tool 실행
 ↓
결과 분석
 ↓
다음 행동 결정

이 루프를 계속 돌리는 것입니다. 그래서 실제 코드에서는 이런 구조가 됩니다.

while not finished:

    response = llm(messages)

    if response.tool:
        result = run_tool(response.tool)
        messages.append(result)

이 루프를 관리하는 시스템이 바로 Agent Runtime입니다.

요즘 많이 쓰이는 프레임워크는 다음과 같습니다.

• - LangGraph

• - AutoGen

• - CrewAI

하지만 흥미로운 점이 있습니다. 많은 팀이 결국 자체 Orchestrator를 만듭니다.

왜냐하면 workflow 구조 , tool 시스템 , UI 이벤트 , 상태 관리 가 서비스마다 전부 다르기 때문입니다.

그래서 Agent 시스템은 종종

“Agent framework로 시작하고
결국 자체 runtime으로 끝난다.”

라는 말도 있습니다.

3. LLM Layer : 모델 선택

Agent 시스템은 하나의 LLM만 쓰지 않는 경우가 많습니다.

대부분 이런 구조를 사용합니다.

Local model
+
Cloud model

예를 들면

Local : Llama , Mistral

Clou : GPT, Claude , Gemini

이 구조를 Hybrid LLM architecture라고 부릅니다.

역할도 보통 이렇게 나눕니다.

Local model : task routing , summarization , simple reasoning

Cloud model : complex reasoning, writing, planning

이렇게 하면 비용 감소 및 latency 감소 , 시스템 통제 라는 장점이 생깁니다.

그래서 실제 Agent 시스템은 대부분 이런 구조로 운영됩니다.

Local LLM
 ↓
simple tasks

Cloud LLM
 ↓
complex tasks

4. Task Queue : Agent는 오래 걸린다

AI Agent 작업은 생각보다 오래 걸립니다. 예를 들어 이런 작업이 있다고 해봅시다.

• - 리서치

• - 보고서 생성

• - 데이터 분석

• - 코드 생성

이 작업들은 몇 초가 아니라 몇 분이 걸릴 수도 있습니다.

그래서 대부분의 Agent 시스템은 Queue 구조를 사용합니다.

API
 ↓
Task Queue
 ↓
Worker
 ↓
Agent runtime

대표적인 기술은 다음과 같습니다.

• - Redis Queue

• - Celery

• - RabbitMQ

• - Kafka

특히 많이 쓰이는 조합은 이것입니다.

Redis
+
Celery

이 조합은 Python 기반 서비스에서 사실상 표준처럼 사용됩니다.

5. State Store : Agent는 기억해야 한다

Agent는 작업 중간에 많은 데이터를 생성합니다.

예를 들어

• - 검색 결과

• - 중간 요약

• - 분석 결과

• - 초안

이 데이터를 저장하지 않으면 Agent는 작업을 이어갈 수 없습니다.

그래서 대부분 Agent 시스템에는 State Store가 존재합니다.

대표적인 저장소는 다음과 같습니다.

Relational : PostgreSQL

Cache : Redis

Semantic memory : Vector DB

예를 들어 이런 조합이 많이 사용됩니다.

PostgreSQL
+
Redis
+
Vector DB

각 역할은 보통 이렇게 나눕니다.

PostgreSQL → task data

Redis → session state

Vector DB → long term memory

6. Tool Execution : Agent의 손과 발

Agent가 실제 작업을 하려면 Tool 실행 환경이 필요합니다.

예를 들어 이런 것들입니다.

• - browser automation

• - python execution

• - file system

• - database query

이 Tool들은 보통 격리된 환경에서 실행됩니다.

왜냐하면 보안 문제 때문입니다. 그래서 이런 기술들이 사용됩니다.

대표적인 방식

Docker

Agent
 ↓
Tool container

또는

Virtual Machine

Agent
 ↓
VM
 ↓
Browser

최근 Agent 시스템에서는 Virtual Computer 개념도 많이 등장합니다.

즉

Agent에게 전용 컴퓨터를 주는 구조

입니다.

7. Event Streaming : Agent 진행 상황

AI Agent는 진행 상황을 보여주는 것이 중요합니다.

예를 들어 ChatGPT를 보면

• - 검색 중

• - 코드 실행 중

• - 결과 생성 중

같은 메시지가 계속 나옵니다. 이것은 사실 이벤트 스트림입니다.

구조는 보통 이렇게 됩니다.

Agent
 ↓
Event Bus
 ↓
Frontend

대표적인 기술은 다음과 같습니다.

• - WebSocket

• - SSE

• - Kafka

특히 많이 사용하는 것은

WebSocket

입니다.

정리

AI Agent 서비스는 단순한 AI 모델이 아닙니다.

실제 시스템 구조는 보통 이런 기술 스택으로 구성됩니다.

API Layer
FastAPI / Node

Agent Runtime
LangGraph / Custom

LLM Layer
GPT / Claude / Llama

Queue
Redis / Celery

State Store
PostgreSQL / Redis / Vector DB

Tool Execution
Docker / VM

Event Stream
WebSocket / Kafka

이 구조를 보면 한 가지 흥미로운 사실을 알 수 있습니다.

AI Agent는 단순한 AI 애플리케이션이 아니라 하나의 운영 시스템에 가깝다는 것입니다.

그리고 앞으로의 AI 서비스는 점점 이런 구조로 발전할 가능성이 높습니다.

LLM
+
Agent Runtime
+
Virtual Computer
+
Distributed Infrastructure

즉 AI는 단순한 모델이 아니라 새로운 형태의 소프트웨어 인프라가 되고 있습니다.